Programming in different directions...
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Oh boy, why don't you tell him to write the whole application in a single class. Define Forms as internal classes, make all variables static/global and insert a global self-destruct button.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
-
I couldn't agree more. But that depends. I've seen projects go downhill because all the unnecessary super uber architecture prevented the project from finishing on time. One of them has been there for 3 years and it's not finished. It should've taken over one year and it was planned to finish in 8 months. On the other hand, critical systems (take real-time banking systems for example), that have continuous evolution and scalability should have a very solid design from start. I haven't gotten there yet, but I always try to prepared myself for that when the day comes.
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
-
I think the same prinicples still apply. Start simple and add as little as possible each time you put the system into production. I've done high performance web services that are literally hammered with thosands of requests 24/7 with live updates to the servers, and having a flexable simple design was even more critical. Complicated systems are way to hard to troubleshoot when you run into an issue.
Curvature of the Mind now with 3D
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
-
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
"I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there." Exactly. I've always found that I've attained that needed balance when I've gotten the behavior allocation correct, which takes thought. When correct, refactoring isn't too bad because it can be done without ripple effects throughout the rest of the code. That allows the design to be "simple" at first yet be easily refactored to fit future needs. By that metric, both designs are bad -- one has extra complexity that clearly isn't needed, the other is too simplistic in its behavior allocation to be easily refactored in the future.
patbob
-
"I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there." Exactly. I've always found that I've attained that needed balance when I've gotten the behavior allocation correct, which takes thought. When correct, refactoring isn't too bad because it can be done without ripple effects throughout the rest of the code. That allows the design to be "simple" at first yet be easily refactored to fit future needs. By that metric, both designs are bad -- one has extra complexity that clearly isn't needed, the other is too simplistic in its behavior allocation to be easily refactored in the future.
patbob
That's exactly the idea I support.
-
Fix the team issues first. Second:
Naerling wrote:
I want to make flexible and reusable software
Many horrible systems have been born from that statement. I've created a few myself. Don't write a single line of code for changes that aren't needed right now. Stick with simple objects and only add interfaces if the class needs it to make the code simpler and easier to understand.
Curvature of the Mind now with 3D
Exactly. Create the ability to reuse code once you have the need by refactoring.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
As described however that is not OO programming. And worst case it is an anti-pattern. http://en.wikipedia.org/wiki/God_object[^]
-
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
As described however that is not OO programming. And worst case it is an anti-pattern. http://en.wikipedia.org/wiki/God_object[^]
Actually, my boss said the same thing last week... Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it :( I am currently on a bit of a quest to learn all about architecture. Those anti-patterns are interesting. Knowing what NOT to do is at least as important as knowing what TO do :thumbsup:
It's an OO world.
-
Thanks for the concern. I did make those interfaces because we needed them. The problem is that my boss does not find interfaces easier... He is all into base classes. So instead of using multiple interfaces he could implement or not (which was what I had made) he now made one base class with a dozen overridable methods X| We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
It's an OO world.
Naerling wrote:
We now have one class that does everything, so implementation is easier and requires less code... Which is his argument for doing it his way.
:doh: He's obviously never studied/understood OOP principles! You DO NOT have a single class that does everything; that's basic OOP.
I'm too lazy to Google it for you.
-
I agree with that, but to scale things that do not have a good design from start is very difficult. I don't mean create incredible design, just very flexible design that can be simple. This adds a little overhead of time, but it's worth it. On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult. I think that there needs to be a balance, never too simple or without thinking on the future and never too complex. But a good design needs to be thought of since the beginning and decide it's complexity from there.
Fabio Franco wrote:
On the worse case scenario, imagine a flat unlayered web site with no Entity classes defined. I've seen that, too simple and too bad. I had to scale it and it was very difficult.
The site I was talking about I had to use bulk loading on a separate thread and spawned 4-5 threads at startup using data readers with ordinal access for performance. The database used tables partitioned on the hour, and used hand coded serialization code to cache results in memcached. All the ORM tools were way to high level for the project. When you have 10 Gigs of hashtables for lookups, managing everything down to the level of choosing structs vs. classes is important. Moving from a more enterprisy layered design to something simpler allowed me to change implementations much more quickly and tune algorithms continuously to match each dataset.
Curvature of the Mind now with 3D
-
Actually, my boss said the same thing last week... Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it :( I am currently on a bit of a quest to learn all about architecture. Those anti-patterns are interesting. Knowing what NOT to do is at least as important as knowing what TO do :thumbsup:
It's an OO world.
Naerling wrote:
Our current application has a Class that does just about anything. My boss identified it as an anti-pattern and a God Object. I guess he did not learn from it
lol. But at least it gives you the opportunity. My opportunity came with a C++ class, one single class, that had over 200 data members, over 200 methods, over 20,000 lines of code and spanned at least 3 source files (not including the .h file.)
