|
A good OO design can give you maintainability and expandability. If your project requires this, you can (and should) do it.
So close to the hardware there is also another aspect: Performance. We are not always in the land of the plenty and sometimes you have to take whatever the processor has to offer. You have to cut some corners and write some 'clever' code to get this performance. This code will be less maintainable and harder to understand. Again, you can do it, but better encapsulate the 'ugly' code in some object and place lots of comments why this had to be done that way.
P.S.: I usually can't wait until the CodeNazis (TM) descend on such code to 'review' it, turn purple and fall off their chairs. They will never unerstand that there is more than one sort of code and that they certainly are not its prophet. 
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
My highly optimized SIMD functions are in facts encapsulated in a class hierarchy that can provide both autodetection of CPU capabilties to choose the appropriate functions (we still have some old Pentium 4 to support) and to set up a fast access higly optimized class to perform those functions on data with set and unchangeable parameters. That was one of my proudest moments 
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
+1 for the CodeNazis (I love Grand Theoretical Programmers [who often change their job title to 'architect' without asking and without understanding what that actually means], usually fresh out of uni, in their first job with no experience delivering projects to customers) 
"Martin Fowler wouldn't write it like this!" they say. "He ain't *!&"ing here!" says I 
I came into this game for the action, the excitement. Go anywhere, travel light, get in, get out, wherever there's trouble, a man alone. Now they got the whole country sectioned off, you can't make a move without a form.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
Brent Jenkins wrote: "Martin Fowler wouldn't write it like this!" they say. "He ain't *!&"ing here!" says I
Awesome. He and Grady Booch are going to be the first against the wall when the revolution comes.
Oh wait.
I forgot about the Lotus Notes development team.
And the entire staff from InstallShield.
And the device driver group at Microsoft...
Software Zen: delete this;
|
|
|
|
|
To be fair, I'll bet most of what I'm told Martin Fowler would or wouldn't do is made up 2 seconds before I'm spoken to. He'd probably be pretty surprised by some of the code I've had to work on.
I worked on a solution containing 159 projects a few years ago. All it did was show a login screen which didn't work properly. Domain driven design to the nth-level of abstraction and plenty of unit tests though, which is all your end customers really care about (although they might not know it themselves)
I came into this game for the action, the excitement. Go anywhere, travel light, get in, get out, wherever there's trouble, a man alone. Now they got the whole country sectioned off, you can't make a move without a form.
modified 31-Aug-21 21:01pm.
|
|
|
|
|
When the code of a project is getting bigger and bigger you need classes to find some order. And also you have reoccuring tasks for what classes are best.
Tip: a function should NEVER be greater than what you can read on your screen. Everything else is "Spaghetti code"
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
YES!
The first thing I do when writing new code is design an appropriate class interface. For a class designed to be non-inheritable (e.g. a complex number class), the interface might be merged into the implementation. If the class is inheritable or polymorphic (e.g. the canonical Shape class), then the interface will be virtual, and separate from the implementation(s).
Working this way forces you to concentrate on the design, rather than rushing to a (possibly) flawed implementation.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
--Winston Churchill
|
|
|
|
|
Yes I do. I do work in embedded real time systems too, albeit loose real time based on extreme computation speed and delocalization of core functionalities rather than dedicated system, and C++ is as bit as powerfuls as advertised.
Most of our codebased is neither encapsulated nor abstract and that's what my team does in the rare R&D time we have allotted: push functionalities that now are global static unssecure and sparse in a full OOP hierarchy where components internals will be independent from the interlas of other components. Maybe in a handful of years we'll be able to ditch the old, cramped and contorted VB6 interface (whic as of now contains a lot fo, eguh, logic) in favor of something new, maybe C#.
DURA LEX, SED LEX
GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
If you think 'goto' is evil, try writing an Assembly program without JMP. -- TNCaver
When I was six, there were no ones and zeroes - only zeroes. And not all of them worked. -- Ravi Bhavnani
|
|
|
|
|
With no connection to languages I do think OO when thinking of software design...
Skipper: We'll fix it.
Alex: Fix it? How you gonna fix this?
Skipper: Grit, spit and a whole lotta duct tape.
|
|
|
|
|
I see no problem with that, when architecture is well defined you don'T get to any of those questions. Using patterns also helps keeping stuff clean and simple. That's what it is about, keeping stuff clean and simple.
Objects <-> Logic <-> UI does a good job on keeping stuff separated and makes it more understandable.
So for example, everything that has to do with database access gets in a separate class for that. You put things together that belong together and keep all stuff to that at one place, makes it easier in my understanding.
I think this could also work for you, if your machine has different physical things. Like this is only for lights, this only for left arm, this only right arm, this only treadmill and so on
(Obviously only makes sense when left and right arm do different things)
Rules for the FOSW ![ ^]
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
|
All good comments. In my rant area, we don't have performance issues. When talking to "the machine" (I like that term), some data items HAVE to be coordinated. Rather than putting it in a class, I have it in multiple places. So, I have bugs in multiple places.
I also DESPISE globals. Sure, like goto's, sometimes they just work. And this code is coming from people who ought to know better.
Well, you've cheered me up. At least some consider these things as useful.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
I try not to. I've dabbled a little.
I've done a lot of C, and what I don't like about C# is that everything must be in a class. (And yet no multi-inheritence.  )
I prefer to use the right tool for the right job.
And please stop referring to VS as a compiler.
|
|
|
|
|
charlieg wrote: I live in the embedded world where our code has to adapt to the reality of real life.
Ironically, that view is one that prevents deep adoption of C++ in the embedded world. There's a widespread perception that C++ includes a lot of overhead that embedded applications can't support. The perception is mistaken. Any loss in performance due to C++ constructs (virtual function calls come to mind) is more than made up by improved engineering. If it's really that much of an issue, C++ can always be treated as "a better 'C'". For that matter, performance requirements that stringent call for custom hardware anyway.
I'm dealing with this myself at the moment. A few months ago I inherited one of our long-term products, which is written in 'C'. The code is over 25 years old. It started life running on two single-board embedded computers, and now runs as a service on a Windows box. It's awful. Globals everywhere. Code reaches up the skirt of data structures without regard to access safety. Hell, it doesn't even follow good structured programming practices half the time. My intent with this crap is to answer questions if necessary. I ain't touching the code with my ten foot pole or anyone else's.
Software Zen: delete this;
|
|
|
|
|
Well, I personally think we always do an OO implementation even when we aren't using an OO language.
It just turns out soooooo much messier and hard to maintain if the language lets you shoot from the hip too much.
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
I totally agree that abstraction and encapsulation are vital - but... there are more ways to skin a cat than just putting it into a class Structs and functions, classes or whatever you want to use, are all just implementation details - appropriately splitting your application into cohesive parts with low coupling is what matters.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
|
C++ was used to teach Object Oriented programming in a University Class I took in Computer Science back in the late 80's. I found it was easy enough to pick up if well presented. I was able to get things to work and that is a big plus. Modern tools are even better than the ones I used then. It also offers Multiple Inheritance which is also a major concept of OO, but also quite a complication if combined with Polymorphism at the same time. If you want an easier language to learn, then I would suggest C# since you can get a good free IDE from Microsoft for that.
|
|
|
|
|
Classes do not exist. Good design does.
|
|
|
|
|
|
...and if it ends with a newline, it is no longer the last line. 
Go figure! 
|
|
|
|
|
lol, correct. The part that had me lost was VS2008 helping me.
Charlie Gilley
<italic>Stuck in a dysfunctional matrix from which I must escape...
"Where liberty dwells, there is my country." B. Franklin, 1783
“They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.” BF, 1759
|
|
|
|
|
In my opinion... every code file should begin and end with a blank line. I don't recall any version of VS hindering that.
modified 22-Nov-16 13:12pm.
|
|
|
|
|
Why? Whitespace at the beginning and end of the file are immaterial to the compiler.
Wait a sec. Let me guess. You produce listings by doing this:
COPY *.CPP LPT1: don't you? 
Software Zen: delete this;
|
|
|
|
|
Maaaybe...  That's "documentation".
Historical reasons, old editors that loaded slowly, typing before it was ready.
And you know I like whitespace.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
